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Status of this Memo 
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Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


This memo describes a generic application protocol kernel for 
connection-oriented, asynchronous interactions called the BEEP 
(Blocks Extensible Exchange Protocol) core. BEEP permits 
simultaneous and independent exchanges within the context of a single 
application user-identity, supporting both textual and binary 
messages. 
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Les 


Introduction 


This memo describes a generic application protocol kernel for 
connection-oriented, asynchronous interactions called BEEP. 


At BEEP’s core is a framing mechanism that permits simultaneous and 
independent exchanges of messages between peers. Messages are 
arbitrary MIME [1] content, but are usually textual (structured using 
XML [2]). 


All exchanges occur in the context of a channel -- a binding to a 
well-defined aspect of the application, such as transport security, 
user authentication, or data exchange. 


Each channel has an associated "profile" that defines the syntax and 
semantics of the messages exchanged. Implicit in the operation of 
BEEP is the notion of channel management. In addition to defining 
BEEP’s channel management profile, this document defines: 


o the TLS [3] transport security profile; and, 
o the SASL [4] family of profiles. 


Other profiles, such as those used for data exchange, are defined by 
an application protocol designer. 
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2. The BEEP Core 


A BEEP session is mapped onto an underlying transport service. A 
separate series of documents describe how a particular transport 
service realizes a BEEP session. For example, [5] describes how a 
BEEP session is mapped onto a single TCP [6] connection. 


When a session is established, each BEEP peer advertises the profiles 
it supports. Later on, during the creation of a channel, the client 
supplies one or more proposed profiles for that channel. If the 
server creates the channel, it selects one of the profiles and sends 
it in a reply; otherwise, it may indicate that none of the profiles 
are acceptable, and decline creation of the channel. 


Channel usage falls into one of two categories: 


initial tuning: these are used by profiles that perform 
initialization once the BEEP session is established (e.g., 
negotiating the use of transport security); although several 
exchanges may be required to perform the initialization, these 
channels become inactive early in the BEEP session and remain so 
for the duration. 


continuous: these are used by profiles that support data exchange; 
typically, these channels are created after the initial tuning 
channels have gone quiet. 


Note that because of their special nature, only one tuning channel 


may be established at any given time; in contrast, BEEP allows 
multiple data exchange channels to be simultaneously in use. 
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2.1 Roles 


Although BEEP is peer-to-peer, it is convenient to label each peer in 
the context of the role it is performing at a given time: 


o When a BEEP session is established, the peer that awaits new 
connections is acting in the listening role, and the other peer, 
which establishes a connection to the listener, is acting in the 
initiating role. In the examples which follow, these are referred 
to as "L:" and "I:", respectively. 


o A BEEP peer starting an exchange is termed the client; similarly, 
the other BEEP peer is termed the server. In the examples which 
follow, these are referred to as "C:" and "S:", respectively. 


Typically, a BEEP peer acting in the server role is also acting ina 
listening role. However, because BEEP is peer-to-peer in nature, no 
such requirement exists. 


2.1.1 Exchange Styles 
BEEP allows three styles of exchange: 
MSG/RPY: the client sends a "MSG" message asking the server to 


perform some task, the server performs the task and replies with a 
"RPY" message (termed a positive reply). 


MSG/ERR: the client sends a "MSG" message, the server does not 
perform any task and replies with an "ERR" message (termed a 
negative reply). 


MSG/ANS: the client sends a "MSG" message, the server, during the 
course of performing some task, replies with zero or more "ANS" 
messages, and, upon completion of the task, sends a "NUL" message, 
which signifies the end of the reply. 


The first two styles are termed one-to-one exchanges, whilst the 
third style is termed a one-to-many exchange. 


Rose Standards Track [Page 6] 


RFC 3080 The BEEP Core March 2001 


2.2 Messages and Frames 


A message is structured according to the rules of MIME. Accordingly, 
each message may begin with "entity-headers" (c.f., MIME’s Section 3 
[11). If none, or only some, of the "entity-headers" are present: 


o the default "Content-Type" is "application/octet-stream"; and, 
o the default "Content-Transfer-Encoding" is "binary". 


Normally, a message is sent in a single frame. However, it may be 
convenient or necessary to segment a message into multiple frames 
(e.g., if only part of a message is ready to be sent). 


Each frame consists of a header, the payload, and a trailer. The 
header and trailer are each represented using printable ASCII 
characters and are terminated with a CRLF pair. Between the header 
and the trailer is the payload, consisting of zero or more octets. 


For example, here is a message contained in a single frame that 
contains a payload of 120 octets spread over 5 lines (each line is 
terminated with a CRLF pair): 


MSG 01 . 52 120 
Content-Type: application/beep+xml 


<start number="1'> 

<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
</start> 
END 


GARA ROED 


In this example, note that the entire message is represented in a 
single frame. 
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2.2.1 Frame Syntax 


The ABNF 


frame 
data 
header 


msg 
rpy 
ans 
err 
nul 


common 
channel 
msgno 
more 
seqno 
size 
ansno 


payload 
trailer 


mapping 


Rose 


[7] 


for a frame is: 
data / mapping 
header payload trailer 


msg / rpy / err / ans / nul 


"MSG" SP common CR 
"RPY" SP common CR 
"ANS" SP common SP ansno CR 
"ERR" SP common CR 
"NUL" SP common CR 


channel SP msgno SP more SP 
0..2147483647 

0..2147483647 

" 7 " / we 

0..4294967295 

0..2147483647 

0..2147483647 


*OCTET 


"END" CR LF 


LF 
LF 
LF 
LF 
LF 


segno SP size 


March 2001 


7; each transport mapping may define additional frames 
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2.2.1.1 Frame Header 


The frame header consists of a three-character keyword (one of: 
"MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more 
parameters. A single space character (decimal code 32, " ") 
separates each component. The header is terminated with a CRLF pair. 


The channel number ("channel") must be a non-negative integer (in the 
range 0..2147483647). 


The message number ("msgno") must be a non-negative integer (in the 
range 0..2147483647) and have a different value than all other "MSG" 
messages on the same channel for which a reply has not been 
completely received. 


The continuation indicator ("more", one of: decimal code 42, "*", or 
decimal code 46, ".") specifies whether this is the final frame of 
the message: 


intermediate ("*"): at least one other frame follows for the 
message; or, 


complete ("."): this frame completes the message. 


The sequence number ("seqno") must be a non-negative integer (in the 
range 0..4294967295) and specifies the sequence number of the first 
octet in the payload, for the associated channel (c.f., Section 
2226142). 


The payload size ("size") must be a non-negative integer (in the 
range 0..2147483647) and specifies the exact number of octets in the 
payload. (This does not include either the header or trailer.) 


Note that a frame may have an empty payload, e.g., 


S: REY O0 1 * 287 20 
S 
S: 
S: END 
S's RPY -0 de -3070 
S: END 
The answer number ("ansno") must be a non-negative integer (in the 


range 0..4294967295) and must have a different value than all other 
answers in progress for the message being replied to. 
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There are two kinds of frames: data and mapping. Each transport 
mapping (c.f., Section 2.5) may define its own frames. For example, 
[5] defines the SEQ frame. The remainder of this section discusses 
data frames. 


When a message is segmented and sent as several frames, those frames 
must be sent sequentially, without any intervening frames from other 
messages on the same channel. However, there are two exceptions: 
first, no restriction is made with respect to the interleaving of 
frames for other channels; and, second, in a one-to-many exchange, 
multiple answers may be simultaneously in progress. Accordingly, 
frames for "ANS" messages may be interleaved on the same channel -- 
the answer number is used for collation, e.g., 


ANS 10 * 0 20 0 


ANS 10 * 20 20 1 


ANS 1 O . 40 10 0 


ANNNNNNNNNN 


which shows two "ANS" messages interleaved on channel 1 as part of a 
reply to message number 0. Note that the sequence number is advanced 
for each frame sent on the channel, and is independent of the 
messages sent in those frames. 
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There are several rules for identifying poorly-formed frames: 


O 


if the header doesn’t start with "MSG", "RPY", "ERR", "ANS", or 
" NUL " Z 


if any of the parameters in the header cannot be determined or are 
invalid (i.e., syntactically incorrect); 


if the value of the channel number doesn’t refer to an existing 
channel; 


if the header starts with "MSG", and the message number refers to 
a "MSG" message that has been completely received but for which a 
reply has not been completely sent; 


if the header doesn’t start with "MSG", and refers to a message 
number for which a reply has already been completely received; 


if the header doesn’t start with "MSG", and refers to a message 
number that has never been sent (except during session 
establishment, c.f., Section 2.3.1.1); 


if the header starts with "MSG", "RPY", "ERR", or "ANS", and 
refers to a message number for which at least one other frame has 
been received, and the three-character keyword starting this frame 
and the immediately-previous received frame for this message 
number are not identical; 


if the header starts with "NUL", and refers to a message number 
for which at least one other frame has been received, and the 
keyword of of the immediately-previous received frame for this 
reply isn't "ANS"; 


if the continuation indicator of the previous frame received on 
the same channel was intermediate ("*"), and its message number 
isn't identical to this frame's message number; 


if the value of the sequence number doesn't correspond to the 
expected value for the associated channel (c.f., Section 2.2.1.2); 
or, 


if the header starts with "NUL", and the continuation indicator is 
intermediate ("*") or the payload size is non-zero. 


If a frame is poorly-formed, then the session is terminated without 
generating a response, and it is recommended that a diagnostic entry 
be logged. 


Rose 
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2.2.1.2 Frame Payload 
The frame payload consists of zero or more octets. 


Every payload octet sent in each direction on a channel has an 
associated sequence number. Numbering of payload octets within a 
frame is such that the first payload octet is the lowest numbered, 
and the following payload octets are numbered consecutively. (When a 
channel is created, the sequence number associated with the first 
payload octet of the first frame is 0.) 


The actual sequence number space is finite, though very large, 
ranging from 0..4294967295 (2**32 - 1). Since the space is finite, 
all arithmetic dealing with sequence numbers is performed modulo 
2**32. This unsigned arithmetic preserves the relationship of 
sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult 
Sections 2 through 5 of [8] for a discussion of the arithmetic 
properties of sequence numbers. 


When receiving a frame, the sum of its sequence number and payload 
size, modulo 4294967296 (2**32), gives the expected sequence number 
associated with the first payload octet of the next frame received. 
Accordingly, when receiving a frame if the sequence number isn’t the 
expected value for this channel, then the BEEP peers have lost 
synchronization, then the session is terminated without generating a 
response, and it is recommended that a diagnostic entry be logged. 
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2.2.1.3 Frame Trailer 


The frame trailer consists of "END" followed by a CRLF pair. 


When receiving a frame, if the characters immediately following the 
payload don’t correspond to a trailer, then the session is terminated 
without generating a response, and it is recommended that a 
diagnostic entry be logged. 
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2.2.2 Frame Semantics 


The semantics of each message is channel-specific. Accordingly, the 
profile associated with a channel must define: 


o the initialization messages, if any, exchanged during channel 
creation; 


o the messages that may be exchanged in the payload of the channel; 
and, 


o the semantics of these messages. 


A profile registration template (Section 5.1) organizes this 
information. 


2.2.2.1 Poorly-formed Messages 


When defining the behavior of the profile, the template must specify 
how poorly-formed "MSG" messages are replied to. For example, the 
channel management profile sends a negative reply containing an error 
message (c.f., Section 2.3.1.5). 


If a poorly-formed reply is received on channel zero, the session is 
terminated without generating a response, and it is recommended that 
a diagnostic entry be logged. 


If a poorly-formed reply is received on another channel, then the 
channel must be closed using the procedure in Section 2.3.1.3. 
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2.3 Channel Management 


When a BEEP session starts, only channel number zero is defined, 
which is used for channel management. Section 6.1 contains the 
profile registration for BEEP channel management. 


Channel management allows each BEEP peer to advertise the profiles 
that it supports (c.f., Section 2.3.1.1), bind an instance of one of 
those profiles to a channel (c.f., Section 2.3.1.2), and then later 


close any channels or release the BEEP session (c.f., Section 
223,212.31) 4 


A BEEP peer should support at least 257 concurrent channels. 
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2.3.1 Message Semantics 
2.3.1.1 The Greeting Message 


When a BEEP session is established, each BEEP peer signifies its 
availability by immediately sending a positive reply with a message 
number of zero that contains a "greeting" element, e.g., 


<wait for incoming connection> 
<open connection> 

RPY OO. 0 110 

Content-Type: application/beep+xml 


<greeting> 
<profile uri=’http://iana.org/beep/TLS’ /> 
</greeting> 
END 
RPY 00.0 52 
Content-Type: application/beep+xml 


<greeting /> 
END 


HHHHHPRP PP ee eae 


Note that this example implies that the BEEP peer in the initiating 
role waits until the BEEP peer in the listening role sends its 
greeting -- this is an artifact of the presentation; in fact, both 
BEEP peers send their replies independently. 


The "greeting" element has two optional attributes ("features" and 
"localize") and zero or more "profile" elements, one for each profile 
supported by the BEEP peer acting in a server role: 


o the "features" attribute, if present, contains one or more feature 
tokens, each indicating an optional feature of the channel 
management profile supported by the BEEP peer; 


o the "localize" attribute, if present, contains one or more 
language tokens (defined in [9]), each identifying a desirable 
language tag to be used by the remote BEEP peer when generating 
textual diagnostics for the "close" and "error" elements (the 
tokens are ordered from most to least desirable); and, 


o each "profile" element contained within the "greeting" element 
identifies a profile, and unlike the "profile" elements that occur 
within the "start" element, the content of each "profile" element 


may not contain an optional initialization message. 


Section 5.2 defines a registration template for optional features. 
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2.3.1.2 The Start Message 


When a BEEP peer wants to create a channel, it sends a "Start" 
element on channel zero, e.g., 


MSG 0 1 . 52 120 
Content-Type: application/beep+xml 


<start number="1'> 

<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
</start> 
END 


4:00:00: 


The "start" element has a "number" attribute, an optional 
"serverName" attribute, and one or more "profile" elements: 


o the "number" attribute indicates the channel number (in the range 
1..2147483647) used to identify the channel in future messages; 


o the "serverName" attribute, an arbitrary string, indicates the 
desired server name for this BEEP session; and, 


o each "profile" element contained with the "start" element has a 
"uri" attribute, an optional "encoding" attribute, and arbitrary 
character data as content: 


* the "uri" attribute authoritatively identifies the profile; 


* the "encoding" attribute, if present, specifies whether the 
content of the "profile" element is represented as a base64- 
encoded string; and, 


* the content of the "profile" element, if present, must be no 
longer than 4K octets in length and specifies an initialization 
message given to the channel as soon as it is created. 


To avoid conflict in assigning channel numbers when requesting the 
creation of a channel, BEEP peers acting in the initiating role use 
only positive integers that are odd-numbered; similarly, BEEP peers 
acting in the listening role use only positive integers that are 
even-numbered. 


The "serverName" attribute for the first successful "start" element 
received by a BEEP peer is meaningful for the duration of the BEEP 
session. If present, the BEEP peer decides whether to operate as the 
indicated "serverName"; if not, an "error" element is sent ina 
negative reply. 
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When a BEEP peer receives a "Start" element on channel zero, it 
examines each of the proposed profiles, and decides whether to use 
one of them to create the channel. If so, the appropriate "profile" 
element is sent in a positive reply; otherwise, an "error" element is 
sent in a negative reply. 


When creating the channel, the value of the "serverName" attribute 
from the first successful "start" element is consulted to provide 
configuration information, e.g., the desired server-side certificate 
when starting the TLS transport security profile (Section 3.1). 


For example, a successful channel creation might look like this: 


MSG 0 1 . 52 178 
Content-Type: application/beep+xml 


<start number=’1'> 
<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
<profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> 
</start> 
END 
RPY 0 1 . 221 87 
Content-Type: application/beep+xml 


<profile uri='http://iana.org/beep/SASL/OTP' /> 
END 


LD LD LD LD LD 00000000 


Similarly, an unsuccessful channel creation might look like this: 


MSG 01 . 52 120 
Content-Type: application/beep+xml 


<start number="'2'> 
<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
</start> 
END 
ERR 0 1 . 221 127 
Content-Type: application/beep+xml 


<error code=’501’>number attribute 
in &lt;start&gt; element must be odd-valued</error> 
END 


NNNNNNAAQAQAAARA 
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Finally, here’s an example in which an initialization element is 
exchanged during channel creation: 


MSG 0 1 . 52 158 
Content-Type: application/beep+xml 


<start number='1'> 
<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA[<ready />]]> 
</profile> 
</start> 
END 
RPY 0 1. 110 121 
Content-Type: application/beep+xml 


<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA[<proceed />]]> 

</profile> 

END 


NNNNNNHnNAADAAAQARQARQAANDN 


Rose Standards Track [Page 19] 


RFC 3080 The BEEP Core March 2001 


2.3.1.3 The Close Message 


When a BEEP peer wants to close a channel, it sends a "close" element 
on channel zero, e.g., 


MSG 0 2 . 235 71 
Content-Type: application/beep+xml 


<close number='"1" code=’200’ /> 
END 


QUO AAA 


The "close" element has a "number" attribute, a "code" attribute, an 
optional "xml:lang" attribute, and an optional textual diagnostic as 
its content: 


o the "number" attribute indicates the channel number; 


o the "code" attribute is a three-digit reply code meaningful to 
programs (c.f., Section 8); 


o the "xml:lang" attribute identifies the language that the 
element’s content is written in (the value is suggested, but not 
mandated, by the "localize" attribute of the "greeting" element 
sent by the remote BEEP peer); and, 


o the textual diagnostic (which may be multiline) is meaningful to 
implementers, perhaps administrators, and possibly even users, but 
never programs. 


Note that if the textual diagnostic is present, then the "xml:lang" 
attribute is absent only if the language indicated as the remote BEEP 
peer’s first choice is used. 


If the value of the "number" attribute is zero, then the BEEP peer 
wants to release the BEEP session (c.f., Section 2.4) -- otherwise 
the value of the "number" attribute refers to an existing channel, 
and the remainder of this section applies. 


A BEEP peer may send a "close" message for a channel whenever all 
"MSG" messages it has sent on that channel have been acknowledged. 
(Acknowledgement consists of the first frame of a reply being 
received by the BEEP peer that sent the MSG "message". ) 


After sending the "close" message, that BEEP peer must not send any 
more "MSG" messages on that channel being closed until the reply to 
the "close" message has been received (either by an "error" message 
rejecting the request to close the channel, or by an "ok" message 
subsequently followed by the channel being successfully started). 
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NOTE WELL: until a positive reply to the request to close the channel 
is received, the BEEP peer must be prepared to process any "MSG" 
messages that it receives on that channel. 


When a BEEP peer receives a "close" message for a channel, it may, at 
any time, reject the request to close the channel by sending an 
"error" message in a negative reply. 


Otherwise, before accepting the request to close the channel, and 
sending an "ok" message in a positive reply, it must: 


O 


Rose 


finish sending any queued "MSG" messages on that channel of its 
own; 


await complete replies to any outstanding "MSG" messages it has 
sent on that channel; and, 


finish sending complete replies to any outstanding "MSG" messages 
it has received on that channel, and ensure that the final frames 
of those replies have been successfully delivered, i.e., 


* for transport mappings that guarantee inter-channel ordering of 
messages, the replies must be sent prior to sending the "ok" 
message in a positive reply; otherwise, 


* the replies must be sent and subsequently acknowledged by the 
underlying transport service prior to sending the "ok" message 
in a positive reply. 
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Briefly, a successful channel close might look like this: 


MSG 0 2 . 235 71 
Content-Type: application/beep+xml 


E 

L 

G 

C: <close number='1' code=’200’ /> 

C: END 

S: RPY 0 2 . 392 46 

S: Content-Type: application/beep+xml 
S 

S 

S 


<ok /> 
END 


Similarly, an unsuccessful channel close might look like this: 


MSG 0 2 . 235 71 
Content-Type: application/beep+xml 


C 

L 

LC 

C: <close number='’1’ code=’200’ /> 

C: END 

S: ERR 0 2 . 392 79 

S: Content-Type: application/beep+xml 
S 

S 

S 


<error code="550'>still working</error> 
END 
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2.3.1.4 The OK Message 


When a BEEP peer agrees to close a channel (or release the BEEP 
session), it sends an "ok" element in a positive reply. 


The "ok" element has no attributes and no content. 
2.3.1.5 The Error Message 


When a BEEP peer declines the creation of a channel, it sends an 
"error" element in a negative reply, e.g., 


MSG 0 1 . 52 115 
Content-Type: application/beep+xml 


<start number="'2'> 
<profile uri='’http://iana.org/beep/FOO’ /> 
</start> 
END 
ERR 0 1 . 221 105 
Content-Type: application/beep+xml 


<error code="550'>all requested profiles are 
unsupported</error> 
END 


Ka a Ka Ka Ka K K K K M K M 


The "error" element has a "code" attribute, an optional "xml:lang" 
attribute, and an optional textual diagnostic as its content: 


o the "code" attribute is a three-digit reply code meaningful to 
programs (c.f., Section 8); 


o the "xml:lang" attribute identifies the language that the 
element’s content is written in (the value is suggested, but not 
mandated, by the "localize" attribute of the "greeting" element 
sent by the remote BEEP peer); and, 


o the textual diagnostic (which may be multiline) is meaningful to 
implementers, perhaps administrators, and possibly even users, but 
never programs. 


Note that if the textual diagnostic is present, then the "xml:lang" 


attribute is absent only if the language indicated as the remote BEEP 
peer’s first choice is used. 
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In addition, a BEEP peer sends an "error" element whenever: 


o it receives a "MSG" message containing a poorly-formed or 
unexpected element; 


o it receives a "MSG" message asking to close a channel (or release 
the BEEP session) and it declines to do so; or 


o a BEEP session is established, the BEEP peer is acting in the 
listening role, and that BEEP peer is unavailable (in this case, 
the BEEP acting in the listening role does not send a "greeting" 
element). 


In the final case, both BEEP peers terminate the session, and it is 
recommended that a diagnostic entry be logged by both BEEP peers. 
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2.4 Session Establishment and Release 


When a BEEP session is established, each BEEP peer signifies its 
availability by immediately sending a positive reply with a message 
number of zero on channel zero that contains a "greeting" element, 
e.g., 


<wait for incoming connection> 
<open connection> 

RPY OO. 0 110 

Content-Type: application/beep+xml 


<greeting> 
<profile uri='http://iana.org/beep/TLS” /> 
</greeting> 
END 
RPY 0 0 . 0 52 
Content-Type: application/beep+xml 


<greeting /> 
END 


HHHHHPRPPeP eee) 


Alternatively, if the BEEP peer acting in the listening role is 
unavailable, it sends a negative reply, e.g., 


<wait for incoming connection> 
<open connection> 

ERR 00 . 0 60 

Content-Type: application/beep+xml 


<error code="421' /> 

END 

RPY 00.0 52 

Content-Type: application/beep+xml 


<greeting /> 

END 

<close connection> 

<close connection> 

<wait for next connection> 


EE d EA, Kal K Kd kal, Ed E ee eae) 


and the "greeting" element sent by the BEEP peer acting in the 
initiating role is ignored. It is recommended that a diagnostic 
entry be logged by both BEEP peers. 
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Note that both of these examples imply that the BEEP peer in the 
initiating role waits until the BEEP peer in the listening role sends 
its greeting -- this is an artifact of the presentation; in fact, 
both BEEP peers send their replies independently. 


When a BEEP peer wants to release the BEEP session, it sends a 
"close" element with a zero-valued "number" attribute on channel 
zero. The other BEEP peer indicates its willingness by sending an 
"ok" element in a positive reply, e.g., 


<close connection> 
<close connection> 
<wait for next connection> 


C: MSG 0 1 . 52 60 

C: Content-Type: application/beep+xml 
Cs 

C: <close code="200' /> 

C: END 

S: RPY 0 1 . 264 46 

S: Content-Type: application/beep+xml 
S: 

S: <ok /> 

S: END 

I: 

L: 

L: 


Alternatively, if the other BEEP doesn’t want to release the BEEP 
session, the exchange might look like this: 


MSG 0 1 . 52 60 
Content-Type: application/beep+xml 


<close code="200' /> 

END 

ERR 0 1 . 264 79 

Content-Type: application/beep+xml 


<error code="550'>still working</error> 
END 


NANNNNAAQAIAAN 


If session release is declined, the BEEP session should not be 
terminated, if possible. 
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2.5 Transport Mappings 


All transport interactions occur in the context of a session -- a 
mapping onto a particular transport service. Accordingly, this memo 
defines the requirements that must be satisfied by any document 
describing how a particular transport service realizes a BEEP 
session. 


2.5.1 Session Management 


A BEEP session is connection-oriented. A mapping document must 


define: 

o how a BEEP session is established; 

o how a BEEP peer is identified as acting in the listening role; 
o how a BEEP peer is identified as acting in the initiating role; 
o how a BEEP session is released; and, 

o how a BEEP session is terminated. 


2.5.2 Message Exchange 


A 


O 


Rose 


BEEP session is message-oriented. A mapping document must define: 
how messages are reliably sent and received; 


how messages on the same channel are received in the same order as 
they were sent; and, 


how messages on different channels are sent without ordering 
constraint. 
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2.6 Asynchrony 


BEEP accommodates asynchronous interactions, both within a single 
channel and between separate channels. This feature allows 
pipelining (intra-channel) and parallelism (inter-channel). 


2.6.1 Within a Single Channel 


A BEEP peer acting in the client role may send multiple "MSG" 
messages on the same channel without waiting to receive the 
corresponding replies. This provides pipelining within a single 
channel. 


A BEEP peer acting in the server role must process all "MSG" messages 
for a given channel in the same order as they are received. Asa 
consequence, the BEEP peer must generate replies in the same order as 
the corresponding "MSG" messages are received on a given channel. 


Note that in one-to-many exchanges (c.f., Section 2.1.1), the reply 
to the "MSG" message consists of zero or more "ANS" messages followed 
by a "NUL" message. In this style of exchange, the "ANS" messages 
comprising the reply may be interleaved. When the BEEP peer acting 
in the server role signifies the end of the reply by generating the 
"NUL" message, it may then process the next "MSG" message received 
for that channel. 


2.6.2 Between Different Channels 


A BEEP peer acting in the client role may send multiple "MSG" 

messages on different channels without waiting to receive the 

corresponding replies. The channels operate independently, in 
parallel. 


A BEEP peer acting in the server role may process "MSG" messages 
received on different channels in any order it chooses. As a 
consequence, although the replies for a given channel appear to be 
generated in the same order in which the corresponding "MSG" messages 
are received, there is no ordering constraint for replies on 
different channels. 
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2.6.3 Pre-emptive Replies 


A BEEP peer acting in the server role may send a negative reply 
before it receives the final "MSG" frame of a message. If it does 
so, that BEEP peer is obliged to ignore any subsequent "MSG" frames 
for that message, up to and including the final "MSG" frame. 


If a BEEP peer acting in the client role receives a negative reply 
before it sends the final "MSG" frame for a message, then it is 
required to send a "MSG" frame with a continuation status of complete 
(".") and having a zero-length payload. 


2.6.4 Interference 
If the processing of a particular message has sequencing impacts on 
other messages (either intra-channel or inter-channel), then the 


corresponding profile should define this behavior, e.g., a profile 
whose messages alter the underlying transport mapping. 
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2.7 Peer-to-Peer Behavior 


BEEP is peer-to-peer 
receive all messages 
initiating BEEP peer 
behave gracefully if 


-- as such both peers must be prepared to 
defined in this memo. Accordingly, an 

capable of acting only in the client role must 
it receives a "MSG" message. Accordingly, all 


profiles must provide an appropriate error message for replying to 
unexpected "MSG" messages. 


As a consequence of the peer-to-peer nature of BEEP, message numbers 


are unidirectionally- 


significant. That is, the message numbers in 


"MSG" messages sent by a BEEP peer acting in the initiating role are 
unrelated to the message numbers in "MSG" messages sent by a BEEP 
peer acting in the listening role. 


For example, these two messages 


application/beep+xml 


Le > 


<profile uri=’http://iana.org/beep/SASL/OTP’ /> 


116 
application/beep+xml 


<profile uri=’http://iana.org/beep/APEX’ /> 


I: MSG 0 1 . 52 120 
I: Content-Type: 

ES 

I: <start number= 
T 

I: </start> 

I: END 

L: MSG 0 1 . 221 

L: Content-Type: 

Lie 

L: <start number='2'> 
Teg 

L: </start> 

L: END 


refer to different messages sent on channel zero. 


Rose 
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3. Transport Security 


When a BEEP session is established, plaintext transfer, without 
privacy, is provided. Accordingly, transport security in BEEP is 
achieved using an initial tuning profile. 


This document defines one profile: 
o the TLS transport security profile, based on TLS version one [3]. 


Other profiles may be defined and deployed on a bilateral basis. 

Note that because of their intimate relationship with the transport 
service, a given transport security profile tends to be relevant to a 
single transport mapping (c.f., Section 2.5). 


When a channel associated with transport security begins the 
underlying negotiation process, all channels (including channel zero) 
are closed on the BEEP session. Accordingly, upon completion of the 
negotiation process, regardless of its outcome, a new greeting is 
issued by both BEEP peers. (If the negotiation process fails, then 
either BEEP peer may instead terminate the session, and it is 
recommended that a diagnostic entry be logged.) 


A BEEP peer may choose to issue different greetings based on whether 
privacy is in use, e.g., 


<wait for incoming connection> 
<open connection> 

RPY 00 . 0 110 

Content-Type: application/beep+xml 


<greeting> 
<profile uri='http://iana.org/beep/TLS” /> 
</greeting> 
END 
RPY 0 0 . 0 52 
Content-Type: application/beep+xml 


<greeting /> 

END 

MSG 0 1 . 52 158 

Content-Type: application/beep+xml 


HHHHHHHH PPP a a RRA 
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<start number='1'> 
<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA[<ready />]]> 
</profile> 
</start> 
END 
RPY 0 1 . 110 121 
Content-Type: application/beep+xml 


<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA[<proceed />]]> 

</profile> 

END 


E ET E EE (EST EKA kel KEL ed: d 


successful transport security negotiation 


RPY 00.0 221 
Content-Type: application/beep+xml 


<greeting> 
<profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> 
<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
<profile uri='’http://iana.org/beep/APEX’ /> 

</greeting> 

END 

RPY OO. 0 52 

Content-Type: application/beep+xml 


<greeting /> 
END 


HHHHHPRPPPeeey|ey E 


Of course, not all BEEP peers need be as single-minded: 


<wait for incoming connection> 
<open connection> 

RPY OO. 0 268 

Content-Type: application/beep+xml 


<greeting> 
<profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> 
<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
<profile uri='http://iana.org/beep/APEX" /> 
<profile uri='http://iana.org/beep/TLS” /> 
</greeting> 
END 
RPY OO. 0 52 
Content-Type: application/beep+xml 


HHHPRPRPPPePeeeyeeyeye 
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<greeting /> 

END 

MSG 0 1 . 52 158 

Content-Type: application/beep+xml 


<start number='1'> 
<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA[<ready />]]> 
</profile> 
</start> 
END 
RPY 01 . 268 121 
Content-Type: application/beep+xml 


<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA[<proceed />]]> 

</profile> 

END 


K a a a a k K G L H K G K K L G M 


failed transport security negotiation 


RPY 00 . 0 268 
Content-Type: application/beep+xml 


<greeting> 
<profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> 
<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
<profile uri='http://iana.org/beep/APEX" /> 
<profile uri='http://iana.org/beep/TLS” /> 
</greeting> 
END 
RPY OO. 0 52 
Content-Type: application/beep+xml 


<greeting /> 
END 


Fa d: b A EE Es 3 
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3.1 The TLS Transport Security Profile 
Section 6.2 contains the registration for this profile. 
3.1.1 Profile Identification and Initialization 
The TLS transport security profile is identified as: 
http://iana.org/beep/TLS 
in the BEEP "profile" element during channel creation. 


During channel creation, the corresponding "profile" element in the 
BEEP "start" element may contain a "ready" element. If channel 
creation is successful, then before sending the corresponding reply, 
the BEEP peer processes the "ready" element and includes the 
resulting response in the reply, e.g., 


MSG 0 1 . 52 158 
Content-Type: application/beep+xml 


<start number='1'> 
<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA[<ready />]]> 
</profile> 
</start> 
END 
RPY 0 1 . 110 121 
Content-Type: application/beep+xml 


<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA [<proceed />]]> 

</profile> 

END 


NNNNnNNNNAADAAAQAAAQAANNI 
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Note that it is possible for the channel to be created, but for the 
encapsulated operation to fail, e.g., 


In this case, a positive reply is sent (as channel creation 


succeeded), but the encapsulated response contains an indication as 


NNNNNNNNAAAARAAQAQAAA 


MSG 0 1 . 52 173 
Content-Type: application/beep+xml 


<start number='1'> 

<profile uri='http://iana.org/beep/TLS' > 
<! [CDATA[<ready version="oops" />]]> 

</profile> 

</start> 

END 

RPY 0 1 . 110 193 

Content-Type: application/beep+xml 


<profile uri='http://iana.org/beep/TLS' > 


<! [CDATA[<error code=’501’>version attribute 
poorly formed in &lt;readyégt; element</error>]]> 


</profile> 
END 


to why the operation failed. 


3.1.2 Message Syntax 


Section 7.2 defines the messages that are used in the TLS transport 
security profile. 


Rose 
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3.1.3 Message Semantics 
3.1.3.1 The Ready Message 


The "ready" element has an optional "version" attribute and no 
content: 


o the "version" element defines the earliest version of TLS 
acceptable for use. 


When a BEEP peer sends the "ready" element, it must not send any 
further traffic on the underlying transport service until a 
corresponding reply ("proceed" or "error") is received; similarly, 
the receiving BEEP peer must wait until any pending replies have been 
generated and sent before it processes a "ready" element. 


3.1.3.2 The Proceed Message 


The "proceed" element has no attributes and no content. It is sent 
as a reply to the "ready" element. 


When a BEEP peer receives the "ready" element, it must not send any 
further traffic on the underlying transport service until it 
generates a corresponding reply. If the BEEP peer decides to allow 
transport security negotiation, it implicitly closes all channels 
(including channel zero), and sends the "proceed" element, and awaits 
the underlying negotiation process for transport security. 


When a BEEP peer receives a "proceed" element in reply to its "ready" 
message, it implicitly closes all channels (including channel zero), 
and immediately begins the underlying negotiation process for 
transport security. 
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4. User Authentication 


When a BEEP session is established, anonymous access, without trace 
information, is provided. Accordingly, user authentication in BEEP 
is achieved using an initial tuning profile. 


This document defines a family of profiles based on SASL mechanisms: 


o each mechanism in the IANA SASL registry [15] has an associated 
profile. 


Other profiles may be defined and deployed on a bilateral basis. 


Whenever a successful authentication occurs, on any channel, the 
authenticated identity is updated for all existing and future 
channels on the BEEP session; further, no additional attempts at 
authentication are allowed. 


Note that regardless of transport security and user authentication, 
authorization is an internal matter for each BEEP peer. As such, 
each peer may choose to restrict the operations it allows based on 
the authentication credentials provided (i.e., unauthorized 
operations might be rejected with error code 530). 
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4.1 The SASL Family of Profiles 
Section 6.3 contains the registration for this profile. 


Note that SASL may provide both user authentication and transport 
security. Once transport security is successfully negotiated for a 
BEEP session, then a SASL security layer must not be negotiated; 
Similarly, once any SASL negotiation is successful, a transport 
security profile must not begin its underlying negotiation process. 


Section 4 of the SASL specification [4] requires the following 
information be supplied by a protocol definition: 


service name: "beep" 


initiation sequence: Creating a channel using a BEEP profile 
corresponding to a SASL mechanism starts the exchange. An 
optional parameter corresponding to the "initial response" sent by 
the client is carried within a "blob" element during channel 
creation. 


exchange sequence: "Challenges" and "responses" are carried in 
exchanges of the "blob" element. The "status" attribute of the 
"blob" element is used both by a server indicating a successful 
completion of the exchange, and a client aborting the exchange, 
The server indicates failure of the exchange by sending an "error" 
element. 


security layer negotiation: When a security layer starts negotiation, 
all channels (including channel zero) are closed on the BEEP 
session. Accordingly, upon completion of the negotiation process, 
regardless of its outcome, a new greeting is issued by both BEEP 
peers. 


If a security layer is successfully negotiated, it takes effect 
immediately following the message that concludes the server’s 


successful completion reply. 


use of the authorization identity: This is made available to all 
channels for the duration of the BEEP session. 


Rose Standards Track [Page 38] 


RFC 3080 


The BEEP Core March 2001 


4.1.1 Profile Identification and Initialization 


Each SASL mechanism registered with the IANA is identified as: 


http://iana.org/beep/SASL/mechanism 


where 
IANA. 


"MECHANISM" is the token assigned to that mechanism by the 


Note that during channel creation, a BEEP peer may provide multiple 
profiles to the remote peer, e.g., 


Rose 


NNNNNAAQAAARAANRA 


MSG 0 1 . 52 178 
Content-Type: application/beep+xml 


<start number='1'> 
<profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> 
<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
</start> 
END 
RPY 0 1 . 221 87 
Content-Type: application/beep+xml 


<profile uri=’http://iana.org/beep/SASL/OTP’ /> 
END 
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During channel creation, the corresponding "profile" element in the 
BEEP "start" element may contain a "blob" element. Note that it is 
possible for the channel to be created, but for the encapsulated 
operation to fail, e.g., 


C: MSG 0 1 . 52 183 

C: Content-Type: application/beep+xml 

C: 

C: <start number=’1’> 

C: <profile uri=’http://iana.org/beep/SASL/OTP’ > 
Cs <! [CDATA [<blob>AGJsb2NrbWF zdGVy</blob>] ]> 
Cr </profile> 

C: </start> 

C: END 

S: RPY 0 1 . 221 178 

S: Content-Type: application/beep+xml 

S: 

S: <profile uri='http://iana.org/beep/SASL/OTP’ > 

S: <! [CDATA[<error code="534'>authentication mechanism is 
S: too weak</error>]]> 

S: </profile> 

S: END 


In this case, a positive reply is sent (as channel creation 
succeeded), but the encapsulated response contains an indication as 
to why the operation failed. 


Otherwise, the server sends a challenge (or signifies success), e.g., 


MSG 0 1 . 52 183 
Content-Type: application/beep+xml 


<start number='1'> 

<profile uri='http://iana.org/beep/SASL/OTP'> 
<! [CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]> 

</profile> 

</start> 

END 

RPY 0 1. 221 171 

Content-Type: application/beep+xml 


<profile uri=’http://iana.org/beep/SASL/OTP’ > 
<! [CDATA [<blob>b3RwLXNoYTEgOTk5NyBwaxh5bwW1zYXM4NTgwNSB1eHQ= 
</blob>]]> 


E K O E D C C CH CICO, C Cl CC 
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</profile> 
S: END 
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Note that this example implies that the "blob" element in the 
server’s reply appears on two lines -- this is an artifact of the 
presentation; in fact, only one line is used. 


If a challenge is received, then the client responds and awaits 
another reply, e.g., 


MSG 1 0 . 0 97 
Content-Type: application/beep+xml 


<blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhl1cmOgdG9In</blob> 
END 

RPY 10.0 66 

Content-Type: application/beep+xml 


<blob status=’complete’ /> 
END 


nnaanaaaaa 


Of course, the client could abort the authentication process by 
sending "<blob status=’abort’ />" instead. 


Alternatively, the server might reject the response with an error: 
e.g., 


MSG 1 0 . 0 97 
Content-Type: application/beep+xml 


<blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhl1cmOgdG9In</blob> 
END 

ERR 1 0 . 0 60 

Content-Type: application/beep+xml 


<error code="535' /> 
END 


LU LD LD LU LD 0000 C 
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Finally, depending on the SASL mechanism, an initialization element 
may be exchanged unidirectionally during channel creation, e.g., 


E 


NNNNNAAQAAANAADAN 


MSG 01 . 52 125 
Content-Type: application/beep+xml 


<start number='1'> 
<profile uri='http://iana.org/beep/SASL/CRAM-MD5” /> 
</start> 
END 
RPY 01 . 221 185 
Content-Type: application/beep+xml 


<profile uri='http://iana.org/beep/SASL/CRAM-MD5'> 

<! [CDATA [<blob>PDE40TYUNjk3MTcwOTUyOHBvc3RvZmZpY2UucmVzdG9uLml 
jaS5uZXQ+</blob>]]> 

</profile> 

END 


Note that this example implies that the "blob" element in the 
server’s reply appears on two lines -- this is an artifact of the 
presentation; in fact, only one line is used. 


4.1.2 Message Syntax 


Section 7.3 defines the messages that are used for each profile in 
the SASL family. 


Note that because many SASL mechanisms exchange binary data, the 
content of the "blob" element is always a base64-encoded string. 


Rose 
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4.1.3 Message Semantics 


The "blob" element has an optional "Status" attribute, and arbitrary 
octets as its content: 


o the "status" attribute, if present, takes one of three values: 


abort: used by a client to indicate that it is aborting the 
authentication process; 


complete: used by a server to indicate that the exchange is 
complete and successful; or, 


continue: used by either a client or server, otherwise. 


Finally, note that SASL’s EXTERNAL mechanism works with an "external 
authentication" service, which is provided by one of: 


o atransport security profile, capable of providing authentication 
information (e.g., Section 3.1), being active on the connection; 


o a network service, capable of providing strong authentication 
(e.g., IPSec [12]), underlying the connection; or, 


o a locally-defined security service. 

For authentication to succeed, two conditions must hold: 

o an external authentication service must be active; and, 

o if present, the authentication identity must be consistent with 
the credentials provided by the external authentication service 
(if the authentication identity is empty, then an authorization 


identity is automatically derived from the credentials provided by 
the external authentication service). 
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5. Registration Templates 
5.1 Profile Registration Template 
When a profile is registered, the following information is supplied: 


Profile Identification: specify a URI [10] that authoritatively 
identifies this profile. 


Message Exchanged during Channel Creation: specify the datatypes that 
may be exchanged during channel creation. 


Messages starting one-to-one exchanges: specify the datatypes that 
may be present when an exchange starts. 


Messages in positive replies: specify the datatypes that may be 
present in a positive reply. 


Messages in negative replies: specify the datatypes that may be 
present in a negative reply. 


Messages in one-to-many exchanges: specify the datatypes that may be 
present in a one-to-many exchange. 


Message Syntax: specify the syntax of the datatypes exchanged by the 
profile. 


Message Semantics: specify the semantics of the datatypes exchanged 
by the profile. 


Contact Information: specify the postal and electronic contact 
information for the author of the profile. 


5.2 Feature Registration Template 


When a feature for the channel management profile is registered, the 
following information is supplied: 


Feature Identification: specify a string that identifies this 
feature. Unless the feature is registered with the IANA, the 
feature’s identification must start with "x-". 


Feature Semantics: specify the semantics of the feature. 


Contact Information: specify the postal and electronic contact 
information for the author of the feature. 
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6. Initial Registrations 
6.1 Registration: BEEP Channel Management 
Profile Identification: not applicable 


Messages exchanged during Channel Creation: not applicable 


Messages starting one-to-one exchanges: "start" or "close" 
Messages in positive replies: "greeting", "profile", or "ok" 
Messages in negative replies: "error" 


Messages in one-to-many exchanges: none 


Message Syntax: c.f., Section 7.1 


Message Semantics: c.f., Section 2.3.1 


Contact Information: c.f., the "Author’s Address" section of this 
memo 


6.2 Registration: TLS Transport Security Profile 
Profile Identification: http://iana.org/beep/TLS 

Messages exchanged during Channel Creation: "ready" 
Messages starting one-to-one exchanges: "ready" 
Messages in positive replies: "proceed" 
Messages in negative replies: "error" 
Messages in one-to-many exchanges: none 


Message Syntax: c.f., Section 7.2 


Message Semantics: c.f., Section 3.1.3 


Contact Information: c.f., the "Author’s Address" section of this 
memo 
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6.3 Registration: SASL Family of Profiles 


Profile Identification: http://iana.org/beep/SASL/mechanism, where 
"mechanism" is a token registered with the IANA 


Messages exchanged during Channel Creation: "blob" 
Messages starting one-to-one exchanges: "blob" 
Messages in positive replies: "blob" 

Messages in negative replies: "error" 

Messages in one-to-many exchanges: none 


Message Syntax: c.f., Section 7.3 


Message Semantics: c.f., Section 4.1.3 


Contact Information: c.f., the "Author’s Address" section of this 
memo 
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6.4 Registration: application/beep+xml 

MIME media type name: application 

MIME subtype name: beep+xml 

Required parameters: none 

Optional parameters: charset (defaults to "UTF-8" [13]) 

Encoding considerations: This media type may contain binary content; 
accordingly, when used over a transport that does not permit 
binary transfer, an appropriate encoding must be applied 

Security considerations: none, per se; however, any BEEP profile 
which uses this media type must describe its relevant security 
considerations 


Interoperability considerations: n/a 


Published specification: This media type is a proper subset of the 
the XML 1.0 specification [2]. Two restrictions are made. 


First, no entity references other than the five predefined general 
entities references ("samp;", "&lt;", "&gt;", "&apos;", and 
"£quot;") and numeric entity references may be present. 


Second, neither the "XML" declaration (e.g., <?xml version="1.0" 
?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be 
present. (Accordingly, if another character set other than UTF-8 
is desired, then the "charset" parameter must be present.) 


All other XML 1.0 instructions (e.g., CDATA blocks, processing 
instructions, and so on) are allowed. 


Applications which use this media type: any BEEP profile wishing to 
make use of this XML 1.0 subset 


Additional Information: none 


Contact for further information: c.f 
of this memo 


- the "Authors Address" section 


Intended usage: limited use 


Author/Change controller: the IESG 
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7. DTDs 
7.1 BEEP Channel Management DTD 
<a 
DTD for BEEP Channel Management, as of 2000-10-29 
Refer to this DTD as: 
<!ENTITY % BEEP PUBLIC "-//IETF//DID BEEP//EN" 
"http://xml.resource.org/profiles/BEEP/beep.dtd"> 


SBEEP; 
--> 


KS 
DTD data types: 


entity syntax/reference example 


a channel number 
CHAN 1..2147483647 al 


authoritative profile identification 
URI c.f., [RFC-2396] http://invisible.net/ 


one or more feature tokens, separated by space 
FTRS NMTOKENS "magic" 


a language tag 
LANG c.f., [RFC-1766] "en", "en-US", etc. 


zero or more language tags 
LOCS NMTOKENS "en-US" 


a 3-digit reply code 


XYZ [1-5] [0-9] [0-9] 500 

==> 

<!ENTITY % CHAN "CDATA"> 

<!ENTITY % URI "CDATA"> 

<!ENTITY % FTRS "NMTOKENS "> 

<!ENTITY % LANG "NMTOKEN"> 

<!ENTITY % LOCS "NMTOKEN"> 

<!ENTITY % XYZ "CDATA"> 
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œl 
BEEP messages, exchanged as application/beep+xml 
role MSG RPY ERR 
I and L greeting error 
I or L start profile error 
I or L close ok error 
--> 
<!ELEMENT greeting (profile) *> 
<!ATTLIST greeting 
features SFTRS; # IMPLIED 
localize SLOCS; "i-default"> 
<!ELEMENT start (profile) +> 
<!ATTLIST start 
number SCHAN; #REQUIRED 
serverName CDATA #IMPLIED> 
<!-- profile element is empty if contained in a greeting --> 
<!ELEMENT profile (#PCDATA) > 
<!ATTLIST profile 
uri SURI; #REQUIRED 
encoding (none |base64) "none"> 
<!ELEMENT close (#PCDATA) > 
<!ATTLIST close 
number %CHAN; Tow 
code SXYZ; #REQUIRED 
xml:lang SLANG; #IMPLIED> 
<!ELEMENT ok EMPTY> 
<!ELEMENT error (#PCDATA) > 
<!ATTLIST error 
code SXYZ; #REQUIRED 
xml:lang SLANG; #IMPLIED> 
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7.2 TLS Transport Security Profile DTD 
AIS > 


DTD for the TLS Transport Security Profile, as of 2000-09-04 


Refer to this DTD as: 


<!ENTITY % TLS PUBLIC "-//IETF//DID TLS//EN" 
"http://xml.resource.org/profiles/TLS/tls.dtd"> 
STLS; 
=-> 


leac 
TLS messages, exchanged as application/beep+xml 


role MSG RPY ERR 
I or L ready proceed error 
=-> 
<!ELEMENT ready EMPTY> 
<!ATTLIST ready 
version CDATA E 
<!ELEMENT proceed EMPTY> 


2001 
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7.3 SASL Family of Profiles DTD 


ASS 
DTD for the SASL Family of Profiles, as of 2000-09-04 
Refer to this DTD as: 
<!ENTITY % SASL PUBLIC "-//IETF//DTD SASL//EN" 
"http://xml.resource.org/profiles/sasl/sasl.dtd"> 
SSASL; 
--> 
aS 


SASL messages, exchanged as application/beep+xml 


role MSG RPY ERR 
Ioor L blob blob error 
--> 
<!ELEMENT blob (#PCDATA) > 
<!ATTLIST blob 
xml:space (default |preserve) 
"preserve" 
status (abort |complete|continue) 


"continue"> 
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8. Reply Codes 


code meaning 
200 success 
421 service not available 
450 requested action not taken 
(e.g., lock already in use) 
451 requested action aborted 
(e.g., local error in processing) 
454 temporary authentication failure 
500 general syntax error 
(e.g., poorly-formed XML) 
501 syntax error in parameters 
(e.g., non-valid XML) 
504 parameter not implemented 
530 authentication required 
534 authentication mechanism insufficient 
(e.g., too weak, sequence exhausted, etc.) 
53:5 authentication failure 
537 action not authorized for user 
538 authentication mechanism requires encryption 
550 requested action not taken 
(e.g., no requested profiles are acceptable) 
553 parameter invalid 
554 transaction failed 
(e.g., policy violation) 
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9. Security Considerations 


The BEEP framing mechanism, per se, provides no protection against 
attack; however, judicious use of initial tuning profiles provides 
varying degrees of assurance: 


1. If one of the profiles from the SASL family is used, refer to 
[4]’s Section 9 for a discussion of security considerations. 


2. If the TLS transport security profile is used (or if a SASL 
security layer is negotiated), then: 


1. A man-in-the-middle may remove the security-related profiles 
from the BEEP greeting or generate a negative reply to the 
"ready" element of the TLS transport security profile. A 
BEEP peer may be configurable to refuse to proceed without an 
acceptable level of privacy. 


2. A man-in-the-middle may cause a down-negotiation to the 
weakest cipher suite available. A BEEP peer should be 
configurable to refuse weak cipher suites. 


3. A man-in-the-middle may modify any protocol exchanges prior 
to a successful negotiation. Upon completing the 
negotiation, a BEEP peer must discard previously cached 
information about the BEEP session. 


As different TLS ciphersuites provide varying levels of security, 
administrators should carefully choose which ciphersuites are 
provisioned. 


As BEEP is peer-to-peer in nature, before performing any task 
associated with a message, each channel should apply the appropriate 
access control based on the authenticated identity and privacy level 
associated with the BEEP session. 
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Appendix B. IANA Considerations 


The IANA registers "beep" as a GSSAPI [14] service name, as specified 
in Section 4.1. 


The IANA maintains a list of: 
o standards-track BEEP profiles, c.f., Section 5.1; and, 


o standards-track features for the channel management profile, c.f., 
Section 5.2. 


For each list, the IESG is responsible for assigning a designated 
expert to review the specification prior to the IANA making the 
assignment. As a courtesy to developers of non-standards track BEEP 
profiles and channel management features, the mailing list 
bxxpwg@invisible.net may be used to solicit commentary. 


The IANA makes the registrations specified in Section 6.2 and Section 
6.3. It is recommended that the IANA register these profiles using 
the IANA as a URI-prefix, and populate those URIs with the respective 
profile registrations. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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